AWSのDockerデプロイサービスを比較する

大瀧隆太

2015.06.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ども、大瀧です。
皆さん、Docker触ってますか?本番での適用事例も増えてきた昨今、そろそろ使ってみようかという方も多いんじゃないかと思います。Docker自体はハイパーバイザなどインフラの依存が少ないのでオンプレミス、クラウドの両方で活用できるのですが、AWSにはDockerによるアプリケーションデプロイを提供するサービスがいくつかあるので、うまく活用したいところですよね。ただ、デプロイサービスは複数あるので、今回はどう異なるのかどう使い分けると良いのかを解説します。Docker利用のメリットは以下のブログ記事が詳しいです。

AWS Elastic BeanstalkがDockerをサポートすると何がうれしいのか｜ Developers.IO

AWSのDockerデプロイサービス

Dockerが利用できるAWSサービスは以下の通りです。ちなみに、現時点でインスタンス実行費用以外はいずれのサービスも無料です。太っ腹！

EC2(Elastic Compute Cloud) : AWSの仮想マシンサービスです。LinuxインスタンスにDockerをインストールして使うほか、KubernetesなどDockerクラスタを組むことも可能です。
ECS(EC2 Container Service) : Dockerクラスタ管理を提供する、マネージドサービスです。Dockerインストール済みのEC2インスタンスでECSエージェントを実行して利用します。
Elastic Beanstalk Docker : AWSのアプリデプロイサービスの1つであるElastic BeanstalkがDockerに対応したものです。こちらもECSと同じくマネージドサービスとしてDockerクラスタ管理を提供します。
Elastic Beanstalk Multi-Container Docker : 最近追加されたBeanstalkのもう一つのDocker実行形態です。内部的にECSが利用され、1インスタンスあたり複数のコンテナ実行がサポートされます。

では比較表をどん、と。

機能	EC2	ECS	Elastic Beanstalk Docker	Elastic Beanstalk Multi-Container Docker
Dockerサポート	○	○	○	○
Amazon Linux以外のAMI利用	可	可	不可	不可
Dockerリポジトリ	任意	必須	任意	必須
クラスタ構成	-	○	△(Auto Scaling利用、コンテナの配置に制約あり)	△(Auto Scaling利用、コンテナの配置に制約あり)
コンテナ可用性	-	○	○(Auto Scaling利用)	○(Auto Scaling利用)
ロードバランサ連携	-	○	○(Auto Scaling利用)	○(Auto Scaling利用)
アプリケーションのデプロイ	-	-	○	○
ログ転送、保存	-	-	○	○

項目ごとにコメントしてみます。

Dockerサポート/AMIの制限

EC2インスタンスでは仮想マシンのroot権が握れるので、AMI(Amazon Machine Image)があれば好みのLinuxディストリビューションにDockerをインストールして利用できます。商用サポートを期待するのであれば、CoreOSやRHEL Atomic Hostを検討するのも良いでしょう。

ECSの場合はECSエージェントを実行していれば任意のディストリビューションで良いようですし、ECSエージェント自体Dockerコンテナで実行するので、ほぼ縛りなしと見なしてよいと思います。一方Beanstalkは、専用AMIからの起動が前提になっているのでディストリビューションはAmazon Linux一択です ^*1。そもそも「Dockerを利用するモチベーションとしてLinux環境に依存したくない」というのもよくある話ですので、Dockerを実行するホストOSにはあまりこだわる必要がないかもしれません。

Dockerリポジトリ

一般的なDockerコンテナのデプロイは、以下のフローで行います。

開発マシンでベースDockerイメージからdocker buildコマンドでカスタムDockerイメージを作成
開発マシンでカスタムDockerイメージをdocker pushコマンドでDockerリポジトリにアップロード
本番マシンでカスタムDockerイメージをdocker pullコマンドでDockerリポジトリからダウンロード
本番マシンでカスタムDockerイメージをdocker runコマンドでDockerコンテナを実行

OSSプロダクトや個人ユースであれば、DockerリポジトリはDocker Hubを利用すると思いますが、業務用の場合はプライベートなDockerリポジトリが求められるケースが多いと思います。EC2およびBeanstalk Dockerでは、Dockerfileおよびデプロイするファイル一式があればインスタンス上で手順1〜4の全てを行うことでDockerリポジトリなしでのフローで対応できます。ただ、デプロイごとにdocker buildが毎回走ることになるので、デプロイに時間がかかる点は注意が必要です。Dockerコンテナの起動の速さというメリットを享受したいのであれば、なんらかのプライベートDockerリポジトリを準備することをお奨めします。BeanstalkであればDocker/Multi-Container Docker両方で@thekentiestさんのローカルDocker Registryが有効です。

Docker Registryはバージョンによる違いや他サービスとの組み合わせなど構築パターンがいくつかあるので、別の記事で改めて紹介したいと思います。

クラスタ構成/コンテナ可用性/ロードバランサ連携

Dockerを実行するインスタンスを複数束ねて使うクラスタ構成については、EC2だと独自に構築することになります。CoreOS FleetであればDockerホストのみで組めますが、Kubernetesの場合は別途Masterサーバーが必要なため、Masterサーバーの可用性や運用など課題があるかと思います。

ECSおよびBeanstalkはクラスタ管理がAWSによってサービスとして提供されますので、可用性/運用コストが省けるのは大きなメリットです。ただ、ECS/Beanstalkともに必要最小限のシンプルなクラスタ機能なので、ダウンタイムの極小化や細かいリソース管理などが要件として上がってくると対応が難しいかもしれません。例えば、ECSのServiceというコンテナスケジューラはコンテナ数を維持することは出来ますが、負荷に応じたコンテナのスケールアウト/インの機能はありません ^*2。また、ECSとBeanstalkでは実装が異なり、BeanstalkではAuto Scalingにこの辺りの機能を頼ることになります ^*3。現在のAuto Scalingはインスタンス単位でのスケールアウト/インおよびHealth Checkになるため、コンテナ単位の管理要件を満たせない可能性があります。

ロードバランサはAWSのELB(Elastic Load Balancing)との連携が前提です。ELB側の制約で、以下の制限があります。

インスタンス単位での登録になるため、同一インスタンスで実行する複数のコンテナを1つのELBの配下に登録することはできない
エクスポートするのホストポート番号は同一にしなければならない(コンテナポートには依存しないが、現在はECS/Beanstalkともにコンテナの動的ポート設定がサポートされない)

リバースプロキシによるトラフィックの転送を自由に構成したい場合には、Nginxコンテナなど独自構成を検討しても良いでしょう。

アプリケーションのデプロイ/ログ転送

Beanstalkはアプリデプロイのサービスということで、Docker/Multi-ContainerともにアプリのデプロイとS3へのログ転送機能がついてきます。Dockerイメージ管理の中でそれらをカバーするのであれば不要ですが、いずれも手軽に設定できるのでオススメです。どちらもホストの所定のディレクトリ配下がデプロイ(/var/app/current/)およびログ転送(/var/log/containers/<コンテナ名>)の対象になります。アプリのデプロイは、Dockerコンテナのボリューム指定でホストとマッピングさせる必要があります。

おまけ : GCP(Google Cloud Platform)との比較

GCPにもDocker関連サービスとして、GKE(Google Container Engine)とGCR(Google Container Registry)があります。GKEはKubernetes MasterとKubernetes Node(旧Minion)がインストール済みのGCEのVMインスタンスを一発起動するサービスです。Kubernetes Master自体の運用はユーザーが行う必要があるので、ECS/Beanstalkとは少し雰囲気の異なるものと考えるのが良いでしょう。一方、GCRはマネージドのプライベートDockerリポジトリサービスとして利用でき、AWSには同等のサービスが未整備の状態です。Dockerイメージの格納はGCS(GCP版S3)を利用するので、データの保存費用がかかることに注意します。

まとめ

AWSのDockerデプロイサービス、いかがでしたでしょうか。それぞれ一長一短、向き不向きがありますので、ユースケースに合わせて適切に選択、活用いただくことを期待します。そういえば、今日まで開催中のAWS Summit 2015ではあまりECS/Beanstalk周りの話題が耳に入ってこないのはなぜでしょうかね。